NOTE: This is about a quick update of the existing version. Nothing to do with the major changes in the development version.

Hello Racers,

A test patch has been in use for a long time and some people would like it to become official.

I would like to ask about a few small changes which are easy and safe to introduce, but would make the version incompatible online. So if they are done, they should be tested for the minimum time before becoming official.

I've been asked a few times about increasing the number of AI per player in multiplayer mode. This is easily done but I'm not that confident to allow the full number of 32 drivers per connection. I feel it's better to test in smaller steps but in this case maybe we could go up a lot from the current maximum of 3. How about to 24?

Some other changes have been requested, for the use of GTR cars for drifting and off-road.

Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.

About off-road use, I found a note from about 10 years ago suggesting to allow the off road tyres on the smaller GTR cars as they have some resemblance to rallycross cars and that could allow some fun racing. I've seen a recent request to allow the FXO GTR to use the off road tyres for rallycross.

So, combining the above two purposes it seems like it could be a good idea to allow the knobbly, hybrid, road and road super tyres on all the GTR cars, and to increase the allowed maximum lock on the XRR and FZR.

Reservations:

It might be a bit unrealistic, allowing such tyres on those cars. The big GTR cars are obviousy not designed for off road use, but if it allows more possibilities for drifting and racing, then it seems like a good thing to allow.

Steering lock being increased a lot, with wide front wheels on double wishbone suspension, might seem to defy reality a bit. But I'm interested to hear what you have to say.


P.S. What I mean by "semi-compatible" is that old hotlaps should still be valid if these lock and tyre choice limits were relaxed. But this new version could not connect with the old version online.

The same fix should be in 6U and any patch since. The LFSOpenVR.dll in 6U has a file date of 8 March 2019 which is only shortly after the one linked 3 posts up. It should give the same results. There shouldn't be any relevant changes in the U12 version that would affect this.

I don't think anyone else has mentioned the HP Reverb except for Ross Burton in this post on the Test Patch thread:
https://www.lfs.net/forum/post/1952241#post1952241

In his case it seems to work well (although his post was before the latest version of the dll). I'd be interested to have a look in the openvr.log file if you attach it here. Sometimes there can be a clue in there. It appears in the LFS folder when you use an OpenVR headset.

EDIT: I see Ross Burton was using the old HP Reverb, not the G2 so it seems you are the first to comment about this headset.

Last edited by Scawen, Sat 2 Jan 2021, 16:37.

Hi, sorry but that is not possible at the moment, as there can only be 3 drivers per computer. So with two computers that is a maximum of one real driver plus 5 AI.

I do have a note for the request to allow more cars per computer as it has been requested a few times. I don't think it is really difficult but it would be an incompatible version as changes are needed on guest and host side.

I'm considering the possibility of a new incompatible version with this change and also a small change to allow more maximum lock on FZR and XRR for drifters.

The problem with incompatible updates is they divide the community between official version users and test patch users so it's important to keep those testing stages as short as possible.

Also I have to keep such updates as safe and minimal as possible because there is so much work to do on the separate development version.

Thank you for the test results!

Sorry I didn't answer your questions in October. I remember seeing your post and thought I should answer but didn't make a note to remind myself to do so.

Test Patch U12 is now available and this problem should be fixed. https://www.lfs.net/forum/thread/93185

Downloads should be a bit faster too.

Quote from WestlY :

about 5 hours last i turn off my dns proxy DoH .. and all works with DoT perferct. i have problem with DoH dns .. SNI off..

That is interesting because it seems you can recreate the skin issue on your system.

I'd be interested to know if U12 fixes that for you.

No. It would be test patch U11 + bug fix.

It's very mysterious so far.

k_badam says he is using the latest test patch. I guess it's not related to the test patch, because it has been going fine since April without any problem. But to confirm that, are any of you getting the same fault with the official version?

Of course the code is designed so that there is a timeout if packets stop arriving.

The screenshot posted by Degats might be a clue. The negative number might indicate corruption (perhaps by a buffer overrun) or an unexpected way through the code.

Degats, would it be possible to share that replay? (Or anyone else who got that problem when starting a replay). If the same thing happens when I try to start the replay then I should be able to catch it. If this is reproducible by any means then I'm sure I'll be able to catch it.

To my mind, something has changed on the server. Otherwise how could copies of LFS develop a bug, several months after release? But of course LFS should not hang or become corrupted, whatever packets the server sends.

I enabled logging with the /log command. There's an http header line I don't remember: ETag: "4a6318a5-a5ac"
I don't know what that means but I'll have a look at how LFS deals with those header lines. At first sight it looks as if it simply ignores lines it doesn't recognise.

One last question, do you think it would be worth disabling skin downloads while we figure this out? If the bug often prevents people joining servers, that is worse than not seeing skins. I can temporarily stop skin downloads with a setting on the master server.

Last edited by Scawen, Wed 28 Oct 2020, 09:52. Reason : corrected wrong user name

Thank you all for the comments!

Quote from EeekiE :

I think there are competing things happening when you accelerate in a rear drive car, and the balance of what wins might depend somewhat on the car itself, as well as any fancy electronics potentially stepping in.

My analog RX-7 has wider tyres at the rear than at the front, and quite a linear and gentle power curve, so unless you’re extremely aggressive the load transfer plays a more dominant role in pushing the car out wide.
Which would be a combination of bigger contact patch mentioned here and more force pressing down on the tyre into the road surface.

I was just testing some lighting updates at the autocross area and was driving around in the LX4 in the dark, when I came across the skid pad and started to test out what we were talking about. I drove around well within the grip limits and did some gentle applications of the throttle.

It turns out that it behaved as you said after all, the front did take a wider line with extra throttle. This was in an LX4 with an open diff and with matching front and rear wheels.

I haven't had a close look at the forces going on, or done any comparisons with other cars. But just wanted to confirm that my original statement was too general or (maybe completely wrong) and that your statement was a very good point.

Quote from Bob Smith :

Now I'm having memories of you taking me down those Wiltshire back roads in your M3. Do you still have that?

Nice to see you, Ben.

Yes I still have the E46 M3 and it still has low mileage! It will be 18 next year.

I don't have time to get into tyre physics at the moment but had some thoughts on it after Eeekie's post.

I think there are some competing effects when the throttle is applied.

1) As Eeekie described, the rear wheels become more loaded, lengthening the contact patch and so requiring less slip angle for a given lateral force. And conversely the front wheels become less loaded, get a shorter contact patch and require more slip angle for a given lateral force. From this point of view the car might take a wider line without any steering adjustment.

2) But there is another effect and that is that a wheel which has a longitudinal force applied, will produce less lateral force for a given slip angle. So from this point of view, a rear wheel drive car with more throttle applied (and no change in steering input) will follow a tighter line because the rear wheels will require a wider slip angle for a given force.

3) There are also other possible competing effects, such as the change in toe and camber due to suspension deflection, and the effect of a limited slip differential.

Now, I definitely may be wrong but I imagine number (2) above to be the dominant effect. I think that is how it is in my car but it would be hard to test unless I can find a skid pad. It may well be that a different effect is dominant in different cars, due to the different mass distributions and other design features. As I apply the throttle there is a whole range of slip angles before the point when the whole contact patch is skidding. Now I'm really not a crazy driver at all these days and don't drive much anyway but there are times when I can accelerate pretty hard out of a roundabout without any danger to myself or others. I can apply a lot of power without actually going sideways and it feels to me like it gets closer to oversteer through that process. It feels very planted and poised as I apply more power. A good part of my mind is focussed on the rear wheels, remembering I used to be a motorcyclist and am very aware of going over the limit. It's a feeling of confidence though and there is a certain joy to it. I believe I get this same feeling in the new physics of LFS, but in the old LFS there are some slight changes of line that don't seem to correspond with reality.

Calculations and algorithms based on models and then the constants adjusted to try to match test rig data available for some tyres, and lateral force figures for some cars and just sometimes we can do lap time comparisons.

So in short - get a benchmark based on models and constants then adjust the constants according to as many real world results as possible.

In practice you can then find the models or assumptions are wrong or don't scale properly then you can read scientific papers on theory of rubber adhesion, etc. and try to figure out how to make sense of such complex phenomena described in seemingly abstract papers with confusing mathematics, into something that can really be implemented into realtime simulation with several cars at the same time.

Quote from Evolution_R :

The other major thing was:
[graphics and physics on separate threads]

But I guess that is maybe after the graphics are done.

Yes this would be helpful for maintaining high frame rate as the CPU still has do do a lot of work asking the graphics card to draw things. So I will be thinking about this probably when I'm on the physics.

Quote from nacim :

Wow, I'm really impressed by the ammount of work put into South City, good job !

@Scawen: You moved histogram generation on the GPU, that's nice to see, and looking at the settings that you got to tweak it, I feel like we saw similar papers for it.
Did you had to move to feature level 11 for it or did you found a way to make it work in feature level 10.0 ?

I did have to use 11 because InterlockedAdd was not allowed in feature level 10 and I couldn't think of another way to add to the histogram buffer.

Some possibilities here, the old 'read back a small texture and analyse on CPU' is still there for test purposes, so could be resurrected for Direct3D 10 GPUs. But I was thinking maybe feature level 10 could use the SDR mode and use time-based exposure instead. That would allow D3D10 graphics cards to use LFS but some things wouldn't be much good, e.g. it would be very dark in a car park.

But I don't know how many people have a Direct3D 10 graphics card as D3D10 was out a relatively short time before D3D11 was available. I think for now I'll keep trying to make sure it can run on them using SDR.

Quote from Aleksandr_124rus :

Nice, but i remember there has problems with merging code of the two LFS builds, how progress is going on now of merging builds with tire physics and graphics, or it is done now?

The new tyre physics is in this new version. So the situation is that it might be a bit hard to try to copy the old tyre physics from the public version, into this new version. I am more motivated to try and update the new tyre physics to an acceptable level. It is nice to drive with but needs some good work on load sensitivity, pressure and temperatures which are not correct.

Quote from MagicFr :

Always nice to see improvements in LFS Well done.
my 2 cents for VR as a only-VR user. and having tested auto-exposure in iRacing.
It doesn't work well in VR as the whole view is taken by the game, opposite to when looking at a game on a monitor ( or triple ) that take only , maybe 25%, of your FOV.

Yes, I found in VR the exposure is calculated as dark if you use the whole view, because so much of the view is the car interior, so then it overexposed the image. So in LFS it limits the exposure check to a smaller square in each eye (both added together for a single exposure histogram). This limited square is 30 degrees each way, equivalent to a 60 degree FOV on a square monitor.

Quote from Tomislav531 :

Man someone has to update lfsworld page :|

Is this something to do with the test patch?

It's not clear what you are saying.

Test Patch U11 is now available with a minor improvement for VR and you can now control the strength of the Horizon Lock.


Changes from 0.6U9 to 0.6U11:

VR:
- Using latest update for OpenVR
- Improved timing of obtaining view each frame

Views:
- Horizon lock now has a strength slider option

Small improvement for ultrawide monitors:
- LFS now assumes 3 screens when aspect ratio is 4:1
- previously assumed 3 screens when aspect ratio was 3:1

Some more updated translations - thank you translators!


DOWNLOAD: https://www.lfs.net/forum/thread/93185

Thank you for the VR test, Pistolero and Drifteris.

Quote from Pistolero 667 :

For exemple the weakest IA like it is right now and the strongest (120%) close to world record.

It's hard to make the AI faster because they are using the same physics and same grip, so it's difficult to give them the skill level of an experienced real driver.

But I have worked on them in the new tyre physics system and I think they are more challenging now. I need to work on the tyre physics after finishing some more graphical updates. I hope to release the new tyre physics with the graphical update.

OpenVR:

Attached to this post is a new LFSOpenVR.dll built with the latest version of OpenVR. There are no other changes and it does not use an extra intermediate texture like the previous DLL test.

It seemed smoother to me, when the frame rate wasn't full there wasn't stuttering. Or maybe that was just the updated SteamVR... I don't know.

How to use it:
- Rename the existing TWO DLLs in your LFS\dll folder LFSOpenVR.dll and openvr_api.dll
- Save these new ones there (both are required for compatibility)
- Start LFS (I recommend the U9 patch)

Thanks for the test. I've now removed the link to U10.

In my D3D11 version, I got good results in VR recently with the Rift but for some reason the OpenVR version does not work well. I'm looking into that. If I can fix it, I don't know if the results might help the Public version but I will check that.

Thanks for the test. LFS with D3D9 is quite heavy on the CPU as all the graphics and physics are loaded onto a single core, so there's no benefit from your 8 cores. I think the real solution is the new D3D11 version but unfortunately I can't give any estimate for when that will be released.

I'm taking this opportunity to update the OpenVR implementation for the D3D11 version. I might update to the latest OpenVR. I'll post here if I find anything or think of anything worth trying in the public version.

Thanks for the test. It's odd that a higher end computer can perform worse with LFS in VR. I can't come up with a sensible suggestion yet, but we can try another stab in the dark.

Attached to this post is a new LFSOpenVR.dll which works a bit differently.

How to use it:
- Rename the existing one in your LFS\dll folder
- Save this one there then start LFS

This DLL copies the render target submitted by LFS into an intermediate texture each frame before submitting it to the VR system. It's more like the way it works with the Rift. I don't really expect it to help but think it's worth a go.

You can use this DLL with the U9 or U10 patch. I guess U9 is a better choice as the thread-based submit probably does some good.

Quote from Scawen :

If the width is 3x the height (or more) it assumes you are using a three screen setup (EDIT: and in that case confines the interface to the centre screen).

I think that is now outdated but I think it might work if it was changed to 4x instead of 3x.

Then it would still detect 3 screen setup if you connected 3 monitors with a 4:3 aspect ratio (12:3 overall -> assume 3 screens). But in the case of your setup it would not assume 3 screens and would display a 16:9 interface.

Quote from nacim :

Hello Scawen,
Thanks for the insight. If you could add this to a test patch I would gladly try it.

I've tried that small change in a test patch now.
It also includes an experimental VR test so it's not the 'official' test patch yet, but you can find it here:
https://www.lfs.net/forum/post/1954788#post1954788

Thanks for the logs. I see LFS resolution adjustment is set to 100% (the "RT size" line near the start is the same as the "size" line near the end).

In the case with SteamVR set to 100% your pre-distortion render target size is 4032x2240. The reason these are bigger than the physical screen resolution is because of the distortion: all parts of the render target further out from the eye centre points are deliberately squashed when they are mapped to the screens inside the headset, to compensate for the lens distortion.

If LFS was set to 225% at this time, that would multiply both X and Y by 1.5 so the render target in-game would be 6048x3360 which is really a massive image to render. It's interesting that you say that doesn't seem to harm performance much. I suppose the graphics card is very powerful and has a lot of memory.

So it looks like the issues really come from somewhere else. Probably the way I've implemented the D3D9->D3D11 texture sharing.

I've tried a small change in 0.6U10 and would like to know if it affects your frame dropping problems at all. It now avoids the use of a thread to submit the frame. The thread was meant to allow LFS to continue processing without waiting for the render to finish. But maybe it causes other problems. It's worth a quick test.


[EDIT: removed link to U10 patch - not recommended]

Changes from 0.6U9 to 0.6U10:

VR test:
- Different method of submitting frame to VR
- Avoiding the use of a thread to submit image
- It's possible this may avoid dropped frames

View setup:
- LFS now assumes 3 screens when aspect ratio is 4:1
- previously assumed 3 screens when aspect ratio was 3:1
- this improves support for ultrawide monitors

Some more updated translations - thank you translators!


DOWNLOAD:

IF YOU ALREADY HAVE 0.6U:
PATCH 0.6U TO 0.6U10 (SELF EXTRACTING ARCHIVE)

[EDIT: removed link to U10 patch - not recommended]

Last edited by Scawen, Tue 7 Apr 2020, 07:45.

Quote from BerdyGaming :

Considering the move to dx11, would introducing a Vulkan port for Linux racers be a viable option (because I know about the dx11-vulkan compatibility) or would it be too much effort for a too small of a community?

I don't really know in the future but in the short and medium timeframe that seems pretty much impossible. I have quite a few things to get done for the release. To learn another graphics system and support it side by side with D3D11 would be a mistake. Even if it might be interesting from a programming viewpoint, I expect it would take months to do. I've just done three months of very intensive work this year while converting to D3D11 (although I did some other things too - not all that time was on the port) so the thought of another port is not something I can imagine now!

I read that D3D12 has similarities with Vulkan so if we are still developing LFS in quite a few years from now, I guess it would be time to make a decision between D3D12 and Vulkan.

Quote from leillo1975 :

Linux Community is "small", but dedicated, collaborative and grateful community.

About Vulkan, use this API make more easy to port the game to another OSs. I don't have any idea about game programming, so I'm not going to contradict the devs, but I know that in recent times Vulkan has come a long way from the first version.

I hope at least devs are trying to execute their game on Linux with DXVK to see if it is compatible.

It's good to hear that D3D11 still can work on Linux, because I don't want to restrict users to Windows. But I'm not so pleased to hear that D3D11 support requires a DX12/Vulkan GPU.

I don't have any plans to set up a Linux computer with a super graphics card to test DXVK - we don't have those kind of resources! As in space, time, money, etc. But hearing all those other games run fine, I would be surprised if LFS didn't.

Quote from nacim :

Hello,

I finally had some time to do some testing, and here are the results:

Thanks for the test. It's interesting that the 'unequal screen widths' can be used to adjust the interface, even when you set the number of left and right side screens to zero.

I think that can be used as a temporary solution but I should try changing the 3-screen detection to 4:1 instead of 3:1 in a test patch, as discussed.

I've done a test and successfully unlocked.

Maybe make sure it really is 0.5F2 (bottom of entry screen) and try again now. Just in case there was any temporary problem with the master server when you tried before.

Quote from nacim :

What's the use of the "CPU generated sky" ? Is it used to generate the ambient Spherical Harmonic or something like that ? Can't you reuse the GPU skybox, downsample it and upload it back to CPU ?

Yes, the CPU sky is for:
- ambient lighting spherical harmonic (for directional ambient lighting)
- maximum brightness value (needed before the GPU sky is generated - see below)
- average sky colour (I'm trying to move away from any uses of this)

The GPU sky can still be stored as a 32-bit SRGB texture, doesn't need to be 64-bit HDR if I know the maximum value (from the CPU) before it is generated on the GPU. Each pixel is then multiplied by (1.0 / max_brightness) so the sky uses the full 24-bit range of colours.

I'd sometimes like to be able to generate things on the GPU and read the texture back into system memory for analysis by the program, and I do this, not in realtime, in a few places:
- baked ambient and artificial lighting render
- path-based echo map
- path-based ambient lighting render for cars (called 'lightmap' in LFS)
- path-based occlusion test (called 'optimiser' in LFS)
- calculating average colours from textures

But as far as I know, reading back the texture from GPU to CPU will always cause a small glitch or hesitation, because the CPU must stop and wait, when it calls GetRenderTargetData, until the GPU is ready to send the data. I'm not sure if this is the case with later versions of DirectX - I think later versions are better for getting data back from the GPU because of compute shaders and so on. But I think this is a limitation with DX9 so I've avoided using that in real time situations. Anyway the CPU sky at 64x64 only takes 3 milliseconds in the debug build, and as it's on that separate thread there is no glitch at all, so I think it's quite good now. The lighting system judges that the sun has moved enough to need a new sky, asks the CPU sky thread to make a new sky, then when the CPU sky is generated a few ms later, the main thread tells the GPU to generate the new sky (seems to take no time at all).

Last edited by Scawen, Thu 14 Nov 2019, 10:18. Reason : typo

In the interests of explaining how development goes...

Warning, totally technical and not interesting for most people!

Most of the day was on restructuring the generated sky system a bit and removing some old code that is no longer needed so that yesterday's test has now become proper code to stay instead of being rapidly hacked in for test purposes. Although generating the sky on the GPU instead of the CPU, which is much faster, there was still a quite perceptible glitch long enough to cause a click in the sound each time a new sky was generated - that can be about once every 20 seconds around sunset / sunrise. The click was in my debug version of LFS and might not have happened in the release build but it's best to make it glitch free in the debug version, then it's sure to be OK in the release build, and also won't annoy me all the time while developing.

The glitch turned out to be because I started a new thread to generate the sky each time. A 'CPU sky' still needs to be generated for reasons related to lighting (in addition to the GPU sky) but now the CPU sky can be much smaller in size because it is not for direct display. Still, it's good to use a separate thread to do it to make use of our multiple core CPUs. The solution to the glitch was to have a sky generation thread running the whole time, just waiting for the command from the weather system to generate a new sky texture when required. It turns out that starting and stopping threads is quite expensive in debug builds.

Quote from Scawen :

There are still some bright pixels around I can look into but they aren't causing random blooms.

While testing the updated sky I was driving around South City at sunset and started looking into the remaining white pixels, now that the worst offenders were cured by bounding the fog exponential. I applied the _centroid interpolation modifier to various inputs to the pixel shader until I located the one that was causing the white pixels. It turned out to be the ambient lighting data from artificial lights. Now I can drive around South City or visit those camera locations at Blackwood without seeing any bright pixels at all.

So, a good day's work, though not the sort of thing that sounds very exciting to most people.